Attack Protection Vectors
◦ The kernel and operating system have been hardened with industry best practices.
◦ The appliance is a read-only environment with a temporary in-memory file system mounted over '/'.
◦ All changes to '/' are lost on reboot/upgrade.
◦ Exceptions apply; changes to /etc, /home, and /var. All persistent data is stored in dedicated partitions/volumes.
◦ The appliance is constructed using a minimal number of software dependencies and tools. In addition, only services dedicated to the functioning of our product are running by default.
◦ LiveNX cryptographic modules deployed for TLS and SSH communication (through OpenSSL system library), are configured with WolfCrypt FIPS 140-2 certified cryptography module (certificates #4605)
◦ The appliance is shipped with a restrictive set of firewall rules which reduce the public facing attack surface.
◦ LiveNX and its dependent services, such as InfluxDB and MongoDB, run under non-root system level accounts. This prevents these services from having sudo level access to the underlying system.
◦ All upgrades are manually triggered events, which require user input, to properly upgrade the appliance. This would prevent automatic supply chain attacks like the SolarWinds attack.
◦ Each release of the products will always be updated to address any security vulnerabilities as of the day of software release. Vulnerabilities found after software release will be addressed as outlined in the section titled Security Patching and Timing.
◦ On AWS and Google Cloud deployments, SSH password-based authentication is disabled, allowing only key based authentication. Azure gives users the option to choose password or key based authentication. All appliances ship with root account disabled